A file server is a computer that provides file service relating to the organization of information on storage devices, such as memories, tapes or disks. The file server or filer may be embodied as a storage system including a multi-protocol storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g., the disks. Each “on-disk” file may be implemented as set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
A storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access services provided by a filer. A protocol server is an example of an application service provided to a client. The client may comprise an application executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. Each client may request the services of the file system on the filer by issuing file system protocol messages (in the form of packets) to the filer over the network. An example of such as service is a request to access a unit of storage, such as a directory. It should be noted, however, that the filer may alternatively be configured to operate as an assembly of storage devices that is directly-attached to a (e.g., client or “host”) computer. Here, a user may request the services of the file system to access (i.e., read and/or write) data from/to the storage devices.
Clients often employ a multi-protocol environment to access the various services and/or resources on a filer. For example, some users of a client might use, e.g., Unix® computer platforms while others may use Windows™ platforms, to access a resource, such as a unit of storage, on the filer. An aspect of Windows networking is the notion of a uniform naming convention (UNC) path that defines a way for a user to refer to the unit of storage on a filer or server. A UNC path is prefixed with the string \\ to indicate resource names on a network. For instance, a UNC path may comprise a server name, a share name and a path name that collectively reference a unit of storage, such as a file or directory. A share is a shared storage resource, such as a directory, which is exported by a Windows server for use by a client. Each share has a property that specifies which users and groups are allowed to access the share, and the type of access allowed, e.g. read or write access. This property of a share thus enables share-level control or security.
A symbolic link (“symlink”) is a Unix structure that introduces a level of indirection with respect to a resource, such as a unit of storage. Instead of representing a name of a file or directory on a Unix platform, the symlink provides a path descriptor to that unit of storage. Symlinks are useful because of the flexibility they provide with respect to the locations of units of storage on a server. In other words, a user can be informed that the user's data is provided at a location specified by a symlink and an administrator, when reconfiguring the location of that data, may easily change the content (path descriptor) for that symlink. Symlinks are particularly useful in the case of conventional network file system (NFS) mount operations where a file system can be “grafted” into a directory to establish a mount point. The actual layout of a NFS file system for a Unix operating system is a function of data stored on a disk (in file structures) combined with the manner in which the disks are mounted.
For example, assume a NFS file system is organized on a Unix server such that a directory /foo has a subdirectory /bar2 included therein. A new directory structure is mounted “on top of” the directory /bar2, where the new structure includes a plurality of files (x) and a plurality of subdirectories (f, g). Assume also that a Unix client transmits a request that includes a symlink sss to the server, wherein the symlink is defined as a path descriptor /foo/bar2. In response to receiving the request, the Unix server resolves the meaning of the symlink sss by substituting the path descriptor /foo/bar2 for that symlink. The NFS file system then parses the path descriptor to resolve directory /foo and subdirectory /bar2 and thereby direct the request to the appropriate unit of storage x, f or g. Thus, the symlink provides a means of introducing a level of indirection into a directory or file. However, the notion of a symlink is undefined in a Windows environment.
One approach that allows Windows users to make use of symlinks involves the use of a conventional Samba software program. Samba is an open-source Windows-compatible “server” running on a Unix operating system platform that provides symlink support by utilizing the underlying Unix operating system to resolve paths, including paths containing symlinks. However, Samba is not an ideal solution because it does not efficiently support the Windows security model. That is, any user can create a symlink to go to any path on the server running Samba, including paths that are not exported by Samba. Since this is often not desirable, an option must be set to force Samba to resolve all symlinks to ensure they do not leave the original share. Moreover, if the destination of a symlink is on a file system that is NFS-mounted on the Samba server system, all requests are directed first to the Samba server which, in turn, passes the requests to the NFS server providing the destination path. Not only does this solution double the total network traffic, but it also imposes substantial additional overhead.
Since native Windows environments do not support Unix symlinks, it is difficult for users to migrate to a multi-protocol storage system, such as a filer, if they are dependent on symlinks in their Windows environments. For example, a Windows client generally has no knowledge of how a NFS client has mounted its storage resources. Information relating to the mounting of storage resources on the filer is typically represented in a symlink file, called a symlink translations file. The symlink.translation file is preferably a text file that is converted internally to a binary image used to facilitate searching and matching on the contents of a symlink.
The symlink.translations file is typically located in the /etc/ directory of a file system implemented by the filer. The file system is organized as a hierarchy of directories starting from a single “root” directory represented by a slash (/). Immediately below the root directory are several system directories that contain information required by the operating system. One such system directory is the /etc/ directory that contains various commands and files, including the symlink.translations file, used for system administration. The symlink.translations file is preferably configured as a table in memory having a plurality of mapping entries; an example of a typical notation of a symlink mapping entry is:                map /foo/bar2/* /vol/vol2/bar2/*        
When a request, such as a common internet file system (CIFS) request, is received from a Windows client having a symlink reference therein, the filer interprets that symlink request by accessing the symlink.translations file within its /etc/ directory. For example, a symlink sss is resolved by comparing the contents of that symlink (/foo/bar2) with the mapping entries of the symlink.translations table to determine whether there is a match. If a match is found, the contents of the symlink are substituted with the latter portion of the map entry (/vol/vol2/bar2) to thereby enable access to the requested unit of storage.
In general, the mapping entries of the symlink.translation table can only securely resolve path descriptors within the same share. If the filer receives a request directed to a share that includes a symlink referencing a path descriptor to a destination that is “outside” of that share, the share-level security protections can be circumvented. As noted, the destination of a symlink depends on the way an NFS client has mounted its file system. If the destination is not local to the filer, the filer would have to assume the role of an NFS client in order to reach the destination. It is undesirable and inefficient to implement an NFS client on a filer merely to solve this problem.
Windows clients typically utilize a distributed file system (DFS) feature that allows a Windows client to access a resource (e.g., a share or path) that is originally attached to a server. If the original server does not have the resource, it can optionally respond to the client with a special “error” message indicating the new location of that resource. The server can generate this special error message through use of a distributed database storing the locations of storage resources for Windows (NT) platforms. DFS thus provides a way to introduce a level of indirection for paths on a Windows platform. That is, the Windows client can request access to a resource by referencing a path descriptor that may be on a different server (destination) than that to which the requested resource was originally attached. The original server may then return an indication of the correct path to that resource.
Notably, DFS provides a secure approach to this level of indirection by, inter alia, requiring the client to establish a new connection (e.g., a conventional network session “connection” in accordance with a conventional connection-oriented network service) to the different server. For example, assume the Windows client issues the following request to an original Windows server to access a unit of storage:                dir \\server1\a        
If the unit of storage is no longer at the specified location, the original server may respond with a special error status “path—not—covered”. The client can then request that the original server provide the new location (destination) of the resource. The original server may then return the correct path to that resource, which may be on a different server. In response to receipt of the correct path, the client establishes a new connection to the different server, which authenticates the connection and checks all share-level access control lists.
Therefore, a feature of the present invention is to provide a technique and mechanism that enables a storage system, such as a filer, to resolve requests from clients to access resources within a multi-protocol environment.
Another feature of the present invention is to provide a technique that enables clients of various protocol environments to access file system resources on a multi-protocol filer by providing a level of indirection with respect to the locations of the resources.
Yet another feature of the present invention is to provide a mechanism that allows a Windows client to make use of a Unix-style type of symbolic link.